home *** CD-ROM | disk | FTP | other *** search
Text File | 1998-11-02 | 88.0 KB | 1,519 lines
DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) NNNNAAAAMMMMEEEE DSO - Dynamic Shared Object TTTTOOOOPPPPIIIICCCC This man page is intended to be both a quick reference and a source of detailed information on Dynamic Shared Objects. It is divided into 4 sections: _G_e_n_e_r_a_l _I_n_f_o_r_m_a_t_i_o_n _a_n_d _O_v_e_r_v_i_e_w _L_i_n_k_i_n_g/_B_u_i_l_d_i_n_g _S_u_g_g_e_s_t_i_o_n_s _P_e_r_f_o_r_m_a_n_c_e _C_o_n_s_i_d_e_r_a_t_i_o_n_s _F_r_e_q_u_e_n_t_l_y _A_s_k_e_d _Q_u_e_s_t_i_o_n_s _a_n_d _D_e_t_a_i_l_e_d _D_i_s_c_u_s_s_i_o_n_s GGGGEEEENNNNEEEERRRRAAAALLLL IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN AAAANNNNDDDD OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW FFFFoooorrrrmmmmaaaatttt A DSO, or Dynamic Shared Object, is an EEEELLLLFFFF format object file, very similar in structure to an executable program but with no "main". It has a shared component, consisting of shared text and read-only data; a private component, consisting of data and the GOT (Global Offset Table); several sections that hold information necessary to load and link the object; and a liblist, the list of other shared objects referenced by this object. Most of the libraries supplied by SGI are available as dynamic shared objects. PPPPIIIICCCC -------- PPPPoooossssiiiittttiiiioooonnnn IIIInnnnddddeeeeppppeeeennnnddddeeeennnntttt CCCCooooddddeeee A DSO is relocatable at runtime; it can be loaded at any virtual address. A consequence of this is that all references to external symbols must be resolved at runtime. References from the private region (.e.g. from private data) are resolved once at load-time; references from the shared region (e.g. from shared text) must go through an indirection table (GOT) and hence have a small performance penalty associated with them. Code compiled for use in a shared object is referred to as PPPPIIIICCCC whereas non-PIC is usually referred to as nnnnoooonnnn----sssshhhhaaaarrrreeeedddd.... Non-shared code and PIC cannot be mixed in the same object. WWWWhhhhaaaatttt HHHHaaaappppppppeeeennnnssss aaaatttt RRRRuuuunnnnttttiiiimmmmeeee???? EEEExxxxeeeecccc loads the main program and then loads the interpreter specified in the main program, generally /usr/lib/libc.so.1 for old 32-bit programs, /usr/lib32/libc.so.1 for new 32-bit programs, and /usr/lib64/libc.so.1 for 64-bit programs, and the interpreter in turns loads rrrrlllldddd((((1111)))),,,, the runtime linking loader, which finishes the exec operation. Starting with main's liblist, rrrrlllldddd loads each shared object on the list that is not marked as delay-load, reads that object's liblist, and repeats the operation until all shared objects have been loaded, in a breadth-first manner. This loading process (breadth first, ignoring delay-loaded objects) results in defining a sequence of objects. Next, rrrrlllldddd allocates storage for COMMON symbols and fixes up symbolic references in each loaded object. (This is necessary because we don't know until runtime PPPPaaaaggggeeee 1111 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) where the object will be loaded.) To do symbol lookup of a given symbol (in the process of of fixing up symbolic references), rld looks in each object's dynamic symbol table in turn (according to the sequence mentioned above). If any ssssttttrrrroooonnnngggg symbol is found that satisfies the reference (ie, has the name of the given symbol and is an external definition) the lookup stops with that symbol. If no ssssttttrrrroooonnnngggg definition is found with that name then the first wwwweeeeaaaakkkk symbol found is accepted as the definition. Next, each object's init code is executed. Finally, control is transferred to "__start" in the main program. The sequence at which the -init code is run is important to apps and DSOs having -init code. The default order is that the objects are taken in the reverse order of the sequence defined in loading. If -init code in one DSO calls a DSO whose -init code has not yet run, then the -init code in the called DSO is run before the called DSO routine is actually called (thus the default order is not followed in such a case). It is an error for DSOs to mutually call one another (even indirectly) from within init sections since neither init section can complete first in such a case (_r_l_d catches this and invokes a fatal-error routine). The init code in delay-loaded DSOs is not run till the DSO is actually loaded (when some routine in it is called it will be loaded). _d_l_o_p_e_n()ed and _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n()ed DSOs are ignored in the symbol lookup mentioned above. As are symbols in any DSO which is loaded at run time by being on the library list of a _d_l_o_p_e_n()ed or _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n()ed DSO. However, if a DSO has its symbols visible for any reason (say it was in the main program liblist) that DSO is not then hidden just because it is *also* on the library list of a _d_l_o_p_e_n()ed or _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n()ed DSO. Be sure to read about qqqquuuuiiiicccckkkkssssttttaaaarrrrtttt,,,, ddddeeeellllaaaayyyyeeeedddd llllooooaaaaddddssss,,,, ssssggggiiiiddddllllaaaadddddddd((((3333)))),,,, ssssggggiiiiddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn((((3333)))),,,, and ddddllllooooppppeeeennnn((((3333)))) as each can affect this general process. LLLLIIIINNNNKKKKIIIINNNNGGGG //// BBBBUUUUIIIILLLLDDDDIIIINNNNGGGG DDDDYYYYNNNNAAAAMMMMIIIICCCC SSSSHHHHAAAARRRREEEEDDDD OOOOBBBBJJJJEEEECCCCTTTTSSSS EEEExxxxaaaammmmpppplllleeee Suppose your library is in an archive _l_i_b_f_o_o._a of object files all of which have been compiled -shared; and it references symbols found in _l_i_b_c._s_o._1, _l_i_b_g_l._s_o, _l_i_b_X_1_1._s_o and _l_i_b_n_e_t_l_s._s_o though most programs will never use the path that requires _l_i_b_n_e_t_l_s._s_o. SGI recommends building your DSO, _l_i_b_f_o_o._s_o, in the following way: ld \ -elf \ -shared \ -no_unresolved \ -rdata_shared \ -soname libfoo.so \ -o libfoo.so \ -all libfoo.a \ -lX11 \ -delay_load -lnetls \ PPPPaaaaggggeeee 2222 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) -lc \ -lgl This builds a DSO called libfoo.so that will request rrrrlllldddd to load libc.so.1, libX11.so, and libgl.so whenever libfoo.so is loaded and will load libnetls.so if it is ever referenced. NNNNOOOOTTTTEEEE:::: If you have any C++ object files among the objects making up your DSO, you must replace lllldddd in the above command with CCCCCCCC. I.e. your command becomes: CC -elf -shared ... -o libfoo.so -all libfoo.a ... However, you do not have to do anything special at all to _u_s_e such C++ DSOs when linking other programs against these DSOs. You can link C++ DSOs into C, C++, or Fortran programs using your usual link commands or link other DSOs against these C++ DSOs without taking any special action. For example, the following link works, with the preceding C++ DSO libfoo.so being properly initialized by rrrrlllldddd at program startup: f77 fortran_prog.o -lfoo CCCCoooonnnnttttrrrroooolllllllliiiinnnngggg TTTThhhheeee SSSSyyyymmmmbbbboooollllssss EEEExxxxppppoooorrrrtttteeeedddd BBBByyyy AAAA DDDDyyyynnnnaaaammmmiiiicccc SSSShhhhaaaarrrreeeedddd OOOObbbbjjjjeeeecccctttt One of the benefits of using dynamic shared objects is the ability to release new versions of that object and still have objects that were linked against the old version, work with the new version. This is impossible to guarantee, if the set of symbols exported by an object cannot easily be understood by the object's creator. lllldddd provides several options that help the developer control which symbols are exported by a dynamic shared object. By default lllldddd does not export symbols that are supplied by a linked-in archive or dynamic shared object. The developer is probably only a consumer of the linked-in object, not an exporter. In a subsequent release, the developer may not require the linked-in object and if the symbols provided by the linked-in object had been exported by the developer's object, the new object would not longer be upwardly compatible with the original version. This behavior can be overridden using the ----eeeexxxxppppoooorrrrttttssss option. This default-symbol-hiding behavior, with respect to archives, is also overridden when building a dynamic shared object from an archive using the ----aaaallllllll option. The developer has greater control over the list of symbols that are exported using options ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll,,,, ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee,,,, ----hhhhiiiiddddddddeeeennnn____ssssyyyymmmmbbbboooollll, or ----hhhhiiiiddddeeeessss____ffffiiiilllleeee. The first two options let the developer specifically list the symbols that are to be exported by the dynamic shared object. The ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll option is followed by a comma separated list of names. The ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee option gives a filename that contains a space separated (including newlines) list of names. If any symbols are PPPPaaaaggggeeee 3333 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) specifically exported, then only those symbols will be exported. All other symbols are automatically hidden. The last two options let the developer specify a list of symbols that are to be not exported by the dynamic shared object. There are two consequences of hiding symbols. First, those symbols will not provide resolution to any undefined symbols in an object that links in the dynamic shared object. Second , any references to that symbol within the dynamic shared object will be resolved internally to the hidden symbol. RRRRuuuulllleeeessss OOOOffff TTTThhhhuuuummmmbbbb Use ----nnnnoooo____uuuunnnnrrrreeeessssoooollllvvvveeeedddd to find unresolved symbols. While it is not always possible to supply all the shared objects that will be referenced by libfoo.so on the link line, in general libraries should be self- contained. This is especially true for subsequent releases of a dynamic shared object. If a dynamic shared object has any unresolved references, they must be resolved by some other loaded object. Having unresolved symbols invites disaster since there is no guarantee that the symbols will be resolved and thus the application may not run. Link against the minimum set of .so's needed. Loading a shared object does carry a cost. Linking against unneeded dynamic shared objects causes them to be loaded even if they are never referenced. lllldddd warns when you have linked against a dynamic shared object that resolves no symbols. When building a C++ dynamic shared object, specify ----eeeexxxxppppoooorrrrttttssss for any dynamic shared object that provides the definitions of classes that classes in the object being created derive from. Specifying ----eeeexxxxppppoooorrrrttttssss in this case ensures that consumers of the object being created can create subclasses of classes provided by that object, without having to know the complete set of dynamic shared objects that will need to be loaded. Using the ----eeeexxxxppppoooorrrrttttssss flag in this case may bring in unwanted symbols. Use the ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll,,,, ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee,,,, ----hhhhiiiiddddddddeeeennnn____ssssyyyymmmmbbbboooollll, or ----hhhhiiiiddddeeeessss____ffffiiiilllleeee options where appropriate. Use ----rrrrddddaaaattttaaaa____sssshhhhaaaarrrreeeedddd to move all read-only data into the shared segment. Unfortunately, there are many programs that write to supposedly read-only data; for this reason, ----rrrrddddaaaattttaaaa____sssshhhhaaaarrrreeeedddd is off by default. The ---- uuuusssseeee____rrrreeeeaaaaddddoooonnnnllllyyyy____ccccoooonnnnsssstttt compiler option is on by default. If you reference the gl, have it last in the link line. Often _l_i_b_g_l._s_o cannot be quickstarted (see below); putting it last allows all the "upstream" objects to still be quickstarted. You can also choose to delay-load _l_i_b_g_l._s_o. This still allows your application to quickstart. Anytime a "downstream" shared object (a referenced object) changes, you should relink in order to quickstart, or run the requickstart tool rrrrqqqqssss((((1111)))) on the object. PPPPaaaaggggeeee 4444 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) Try to minimize inter-DSO data references. Try to minimize the use of global data. In DSOs, it is generally more efficient to malloc space when needed rather than use a large static data structure. Try to pack data together that is likely to be unmodified. This allows the kernel to make more of the data pages shared, copy-on-write. Use the ----ddddeeeellllaaaayyyy____llllooooaaaadddd option on any shared object on the link line that is not often used. This adds a small performance penalty for references to it, but can save time and memory for those programs that don't use it. Do not call sssspppprrrroooocccc from any code that may be executed at init time. PPPPEEEERRRRFFFFOOOORRRRMMMMAAAANNNNCCCCEEEE CCCCOOOONNNNSSSSIIIIDDDDEEEERRRRAAAATTTTIIIIOOOONNNNSSSS QQQQuuuuiiiicccckkkkssssttttaaaarrrrtttt When building a shared object or an executable, lllldddd assigns addresses to the object and attempts to resolve all references. At runtime, if rrrrlllldddd verifies that the same set of objects are loaded at the original addresses, then rrrrlllldddd can skip all the runtime relocation work and let the program run. This saves time by skipping doing the relocations and saves memory since rrrrlllldddd does not have to read in the sections that hold the relocation information. At static link time, lllldddd resolves each unresolved function call to a stub routine which references an rrrrlllldddd function called llllaaaazzzzyyyy____tttteeeexxxxtttt____rrrreeeessssoooollllvvvveeee(((()))).... When invoked at runtime, it performs the relocation needed for all future calls to the original function. In this way, more programs can quickstart even if some of the function references are not resolved at static link time. Quickstart fails whenever the dynamic shared objects on a system do not match the objects used when linking and application or the shared objects that it depends on. This will occur whenever a new version of a dynamic shared object is released. When quickstart fails rrrrlllldddd has to do a significant amount of work. The rrrrqqqqssss((((1111)))) command can be used to recalculate the quickstart information associated with an application or a dynamic shared object. rrrrqqqqssss must be called in proper order so that dynamic shared objects on an objects liblist are requickstarted before the object ir requickstarted. rrrrqqqqssss will rewrite the object it is requickstarting back in place. It is possible to mark an object as non- requickstartable by using the ----nnnnoooo____rrrrqqqqssss flag to lllldddd.... AAAAvvvvooooiiiiddddiiiinnnngggg GGGGrrrraaaattttuuuuiiiittttoooouuuussss SSSShhhhaaaarrrreeeedddd OOOObbbbjjjjeeeecccctttt LLLLooooaaaaddddssss Since for each shared object that is loaded rrrrlllldddd does a considerable amount of work and can use up large amounts of real memory it is advantageous to not link against shared objects that are not needed. PPPPaaaaggggeeee 5555 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) RRRReeeedddduuuucccciiiinnnngggg tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff CCCCoooonnnnfffflllliiiiccccttttssss Whenever more than one shared object (including the main program) needed by an executable define and use the same name for a symbol, this is called a ccccoooonnnnfffflllliiiicccctttt and the name for which multiple definitions exist is recorded in your program in the section named ".conflict" The names of all conflicting symbols pertaining to a program can be obtained via the ----DDDDcccc flag to eeeellllffffdddduuuummmmpppp.... One example of a conflict is the routine mmmmaaaalllllllloooocccc which is defined both in lllliiiibbbbcccc....ssssoooo....1111 and in lllliiiibbbbmmmmaaaalllllllloooocccc....ssssoooo.... Conflicts represent extra work to be done at startup, because the presence of a conflict means that the objects in the link may not have chosen a consistent instance of the symbol in question. This extra work is memory-intensive, since even the presence of one conflict may mean that many pages of memory must be examined by rrrrlllldddd which would otherwise have not been needed for a quickstarting program. The ----qqqquuuuiiiicccckkkkssssttttaaaarrrrtttt____iiiinnnnffffoooo flag makes lllldddd print out a warning about every conflict it finds and the names of two of the objects in which it is defined. Of course, sometimes conflicts are a necessary part of the design of certain applications. ddddllllooooppppeeeennnn((((3333)))),,,, ssssggggiiiiddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn((((3333)))),,,, ssssggggiiiiddddllllaaaadddddddd((((3333)))),,,, aaaannnndddd ddddeeeellllaaaayyyyeeeedddd llllooooaaaaddddssss The overhead associated with objects that are referenced but seldom actually used can be mitigated by using ddddllllooooppppeeeennnn((((3333)))),,,, ssssggggiiiiddddllllooooppppeeeennnn____vvvveeeerrrrssssiiiioooonnnn((((3333)))),,,, ssssggggiiiiddddllllaaaadddddddd((((3333)))),,,, or ddddeeeellllaaaayyyyeeeedddd llllooooaaaaddddssss.... The use of any of these, delays the loading of a shared object (and the objects on it's liblist) until it is actually referenced. The most convenient is the ----ddddeeeellllaaaayyyy____llllooooaaaadddd option to lllldddd.... All three require that there be no references from any other objects' data section to the delay loaded shared object. FFFFRRRREEEEQQQQUUUUEEEENNNNTTTTLLLLYYYY AAAASSSSKKKKEEEEDDDD QQQQUUUUEEEESSSSTTTTIIIIOOOONNNNSSSS List of Questions: 1111)))) WWWWhhhhaaaatttt iiiissss DDDDSSSSOOOO???? 2222)))) HHHHoooowwww ddddoooo ddddyyyynnnnaaaammmmiiiicccc sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeeccccttttssss ccccoooommmmppppaaaarrrreeee wwwwiiiitttthhhh sssshhhhaaaarrrreeeedddd lllliiiibbbbrrrraaaarrrriiiieeeessss???? 3333)))) HHHHoooowwww ddddoooo IIII mmmmaaaaiiiinnnnttttaaaaiiiinnnn bbbbiiiinnnnaaaarrrryyyy ccccoooommmmppppaaaattttiiiibbbbiiiilllliiiittttyyyy bbbbeeeettttwwwweeeeeeeennnn vvvveeeerrrrssssiiiioooonnnnssss ooooffff DSOs?" 4444)))) UUUUnnnnddddeeeerrrr wwwwhhhhiiiicccchhhh vvvveeeerrrrssssiiiioooonnnnssss ooooffff tttthhhheeee OOOOSSSS ccccaaaannnn IIII uuuusssseeee DDDDSSSSOOOO???? 5555)))) WWWWhhhhaaaatttt oooobbbbjjjjeeeecccctttt----ffffiiiilllleeee ffffoooorrrrmmmmaaaatttt ddddooooeeeessss DDDDSSSSOOOO uuuusssseeee???? 6666)))) HHHHoooowwww ddddoooo IIII iiiinnnnssssttttaaaallllllll tttthhhheeee ttttoooooooollllssss ssssoooo IIII ccccaaaannnn uuuusssseeee DDDDSSSSOOOO oooonnnn mmmmyyyy ssssyyyysssstttteeeemmmm???? 7777)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee tttthhhhaaaatttt uuuusssseeeessss aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? 8888)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee tttthhhhaaaatttt ddddooooeeeessssnnnn''''tttt uuuusssseeee sssshhhhaaaarrrreeeedddd linking?" 9999)))) HHHHoooowwww ddddoooo IIII tttteeeellllllll iiiiffff aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee wwwwiiiillllllll uuuusssseeee ddddyyyynnnnaaaammmmiiiicccc lllliiiinnnnkkkkiiiinnnngggg???? 11110000)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? 11111111)))) WWWWhhhheeeerrrreeee ddddooooeeeessss tttthhhheeee ssssyyyysssstttteeeemmmm llllooooooookkkk ffffoooorrrr sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeeccccttttssss aaaatttt rrrruuuunnnnttttiiiimmmmeeee???? 11112222)))) WWWWhhhhaaaatttt iiiissss QQQQuuuuiiiicccckkkkssssttttaaaarrrrtttt???? 11113333)))) WWWWhhhhaaaatttt iiiissss tttthhhheeee ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee???? PPPPaaaaggggeeee 6666 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) 11114444)))) WWWWhhhhaaaatttt ddddiiiirrrreeeeccccttttiiiivvvveeeessss ccccaaaannnn bbbbeeee ppppuuuutttt iiiinnnn aaaa ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee???? 11115555)))) WWWWhhhhaaaatttt iiiissss ////uuuussssrrrr////lllliiiibbbb////ssssoooo____llllooooccccaaaattttiiiioooonnnnssss???? 11116666)))) IIIIffff IIII ddddoooonnnn''''tttt hhhhaaaavvvveeee aaaa vvvvaaaalllliiiidddd ssssoooo____llllooooccccaaaattttiiiioooonnnnssss,,,, ccccaaaannnn IIII ggggeeeennnneeeerrrraaaatttteeee oooonnnneeee ffffrrrroooommmm all the .so's in, say, /usr/lib?" 11117777)))) HHHHoooowwww eeeexxxxppppeeeennnnssssiiiivvvveeee iiiissss iiiitttt ((((aaaatttt rrrruuuunnnnttttiiiimmmmeeee)))) ttttoooo NNNNOOOOTTTT uuuusssseeee tttthhhheeee -update_registry option?" 11118888)))) HHHHoooowwww aaaannnndddd wwwwhhhheeeennnn wwwwiiiillllllll QQQQuuuuiiiicccckkkkssssttttaaaarrrrtttt bbbbeeee uuuusssseeeedddd???? 11119999)))) WWWWhhhhaaaatttt aaaabbbboooouuuutttt rrrruuuunnnn----ttttiiiimmmmeeee llllooooaaaaddddiiiinnnngggg uuuunnnnddddeeeerrrr uuuusssseeeerrrr ccccoooonnnnttttrrrroooollll???? 22220000)))) WWWWhhhhaaaatttt bbbbeeeennnneeeeffffiiiittttssss wwwwiiiillllllll IIII ggggeeeetttt ffffrrrroooommmm DDDDSSSSOOOO???? 22221111)))) WWWWhhhhaaaatttt ccccoooossssttttssss aaaarrrreeee aaaassssssssoooocccciiiiaaaatttteeeedddd wwwwiiiitttthhhh DDDDSSSSOOOO???? 22222222)))) WWWWhhhhaaaatttt iiiissss tttthhhheeee ----KKKKPPPPIIIICCCC ooooppppttttiiiioooonnnn???? 22223333)))) MMMMuuuusssstttt mmmmaaaaiiiinnnn pppprrrrooooggggrrrraaaammmmssss wwwwhhhhiiiicccchhhh wwwwaaaannnntttt ttttoooo uuuusssseeee DDDDSSSSOOOOssss uuuusssseeee ----KKKKPPPPIIIICCCC ffffoooorrrr compilation?" 22224444)))) HHHHoooowwww ddddoooo IIII cccchhhhaaaannnnggggeeee mmmmyyyy aaaasssssssseeeemmmmbbbbllllyyyy llllaaaannnngggguuuuaaaaggggeeee ssssoooouuuurrrrcccceeeessss ttttoooo uuuusssseeee ----KKKKPPPPIIIICCCC???? 22225555)))) CCCCaaaannnn IIII mmmmiiiixxxx IIIIRRRRIIIIXXXX 4444 ssssttttaaaattttiiiicccc sssshhhhaaaarrrreeeedddd lllliiiibbbbrrrraaaarrrriiiieeeessss wwwwiiiitttthhhh DDDDSSSSOOOOssss???? 22226666)))) WWWWhhhhaaaatttt ooooppppttttiiiioooonnnnssss ddddoooo IIII hhhhaaaavvvveeee wwwwhhhheeeennnn bbbbuuuuiiiillllddddiiiinnnngggg aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? 22227777)))) WWWWhhhhaaaatttt ppppiiiittttffffaaaallllllllssss sssshhhhoooouuuulllldddd IIII kkkknnnnoooowwww aaaabbbboooouuuutttt wwwwhhhhiiiicccchhhh aaaarrrreeee aaaassssssssoooocccciiiiaaaatttteeeedddd wwwwiiiitttthhhh DSO?" 22228888)))) WWWWhhhhaaaatttt sssshhhhoooouuuulllldddd IIII ddddoooo aaaabbbboooouuuutttt aaaa GGGGOOOOTTTT oooovvvveeeerrrrfffflllloooowwww???? 22229999)))) HHHHoooowwww aaaarrrreeee mmmmuuuullllttttiiiipppplllleeee vvvveeeerrrrssssiiiioooonnnnssss ooooffff DDDDSSSSOOOOssss ssssuuuuppppppppoooorrrrtttteeeedddd???? 33330000)))) WWWWhhhhyyyy aaaarrrreeee tttthhhheeee gggglllloooobbbbaaaallll oooobbbbjjjjeeeeccccttttssss iiiinnnn mmmmyyyy CCCC++++++++ DDDDSSSSOOOO nnnnooootttt bbbbeeeeiiiinnnngggg iiiinnnniiiittttiiiiaaaalllliiiizzzzeeeedddd???? 33331111)))) WWWWhhhheeeerrrreeee ccccaaaannnn IIII ffffiiiinnnndddd mmmmoooorrrreeee ddddooooccccuuuummmmeeeennnnttttaaaattttiiiioooonnnn oooonnnn DDDDSSSSOOOO???? 1111)))) WWWWhhhhaaaatttt iiiissss DDDDSSSSOOOO???? DSO stands for Dynamic Shared Object. DSO provides a capability similar to static shared libraries under IRIX4 and earlier, e.g., it gives applications the ability to share the text of heavily used libraries, which need not be included in the executable file. However DSO has two important distinctions from static shared libraries. 2222)))) HHHHoooowwww ddddoooo ddddyyyynnnnaaaammmmiiiicccc sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeeccccttttssss ccccoooommmmppppaaaarrrreeee wwwwiiiitttthhhh ssssttttaaaattttiiiicccc sssshhhhaaaarrrreeeedddd lllliiiibbbbrrrraaaarrrriiiieeeessss???? First, a dynamic shared object contains only position-independent code, so that it may be mapped into the virtual address space of different processes at different addresses and still be shared. Second, dynamic shared objects, and indeed the executable itself are mapped in by a runtime loader, rld, which resides in memory in the same address space as the executable. This gives the system the ability to change the binding of symbols during executions, at the request of the executing program. 3333)))) HHHHoooowwww ddddoooo IIII mmmmaaaaiiiinnnnttttaaaaiiiinnnn bbbbiiiinnnnaaaarrrryyyy ccccoooommmmppppaaaattttiiiibbbbiiiilllliiiittttyyyy bbbbeeeettttwwwweeeeeeeennnn vvvveeeerrrrssssiiiioooonnnnssss ooooffff DDDDSSSSOOOOssss???? As long as the shared objects maintain the same exported symbols, or perhaps add new symbols without removing any or changing semantics, and don't change exported structures, they will be binary compatible. Ordering of symbols, routines and global data are irrelevant. 4444)))) UUUUnnnnddddeeeerrrr wwwwhhhhiiiicccchhhh vvvveeeerrrrssssiiiioooonnnnssss ooooffff tttthhhheeee OOOOSSSS ccccaaaannnn IIII uuuusssseeee DDDDSSSSOOOO???? DSO is available under IRIX versions 5.0 and later. Programs built with DSO will not work on earlier version of IRIX. PPPPaaaaggggeeee 7777 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) 5555)))) WWWWhhhhiiiicccchhhh oooobbbbjjjjeeeecccctttt----ffffiiiilllleeee ffffoooorrrrmmmmaaaatttt ddddooooeeeessss DDDDSSSSOOOO uuuusssseeee???? DSO uses the ELF object file format, as defined in the SVR4 ABI. ELF objects cannot be run under IRIX 4.0.5 or earlier. 6666)))) HHHHoooowwww ddddoooo IIII iiiinnnnssssttttaaaallllllll tttthhhheeee ttttoooooooollllssss ssssoooo IIII ccccaaaannnn uuuusssseeee DDDDSSSSOOOO oooonnnn mmmmyyyy ssssyyyysssstttteeeemmmm???? IRIX 5.0 and later releases all support and use DSOs. In order to compile and build shared objects you will need to have the Developer's Option installed. 7777)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee tttthhhhaaaatttt uuuusssseeeessss aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? cc myfile.c -lmine This will link you with libmine.so and also with libc.so.1, if either are available. If no libmine.so is available, but there is a libmine.a, the libmine.a will be used along with libc.so.1, and you will still get dynamic linking. To be explicit, add the ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd flag to the cc line: cc -call_shared myfile.c -lmine 8888)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee tttthhhhaaaatttt ddddooooeeeessssnnnn''''tttt uuuusssseeee sssshhhhaaaarrrreeeedddd lllliiiinnnnkkkkiiiinnnngggg???? Use the ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd ffffllllaaaagggg:::: cc -non_shared myfile.c -lmine Some libraries are not and will not be available non-shared. The ones that are available are not installed by default, so one must request their installation. In general, the user of -non_shared is deprecated. 9999)))) HHHHoooowwww ddddoooo IIII tttteeeellllllll iiiiffff aaaannnn eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee wwwwiiiillllllll uuuusssseeee ddddyyyynnnnaaaammmmiiiicccc lllliiiinnnnkkkkiiiinnnngggg???? elfdump -o shows you the ELF program header. This contains all the information necessary for _e_x_e_c and _r_l_d to run the program/shared object. Only a.outs which use dynamic linking will have a PHDR, INTERP, or DYNAMIC entry. An example and a more detailed description follows: % elfdump -o /bin/cat ***PROGRAM HEADER*** Type Offset Vaddr Paddr Filesz Memsz Align RWX PHDR 0x00000034 0x00400034 0x00400034 0x000000c0 0x00000000 0x00000004 r-- INTERP 0x00000100 0x00400100 0x00400100 0x00000009 0x00000009 0x00000004 r-- REGINFO 0x00000110 0x00400110 0x00400110 0x00000018 0x00000018 0x00000004 r-- DYNAMIC 0x00000150 0x00400150 0x00400150 0x00000a70 0x00000a70 0x00000010 r-- LOAD 0x00000000 0x00400000 0x00400000 0x00003000 0x00003000 0x00001000 r-x LOAD 0x00003000 0x10000000 0x10000000 0x00001000 0x00001290 0x00010000 rwx PPPPaaaaggggeeee 8888 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) Each line is an entry in the program header, and refers to a "segment" of the file. PPPPHHHHDDDDRRRR points to the program header itself within the file. Only executables which use dynamic linking will have this field. IIIINNNNTTTTEEEERRRRPPPP points to a place in the file where the name of the interpreter required for this program is to be found. For any ABI-conforming object, this name will be "/usr/lib/libc.so.1". RRRREEEEGGGGIIIINNNNFFFFOOOO points to a place in the file where information about register setup can be found. Currently this mostly consists of the correct gp value for this object. DDDDYYYYNNNNAAAAMMMMIIIICCCC points to the information in the file which is needed by rld to execute it correctly. This information includes the liblist, a symbol table, and other information. LLLLOOOOAAAADDDD points to segments that are to be mapped into the memory image. The columns give various information about each segment. OOOOffffffffsssseeeetttt is the offset in the file to the beginning of the segment. VVVVaaaaddddddddrrrr is the virtual address of the beginning of the segment in the memory image of the file, ASSUMING that it was mapped as described in the LOAD entries PPPPaaaaddddddddrrrr is the same as Vaddr in our implementation. FFFFiiiilllleeeesssszzzz is the size of the segment in the file. MMMMeeeemmmmsssszzzz is the size of the segment in the memory image. When this is larger it is assumed to be zero-filled. AAAAlllliiiiggggnnnn is the alignment required by this section. If an segment is to be mapped somewhere into memory other than at Vaddr, the new address must be congruent to Vaddr modulo the alignment. In the example above, the first segment must always be loaded at a page boundary, and the second must always be loaded at a 64K boundary. PPPPaaaaggggeeee 9999 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) RRRRWWWWXXXX specifies the protections r(ead), w(rite), or x(ecute) for the segment. Programs which are linked ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd do not have a PHDR, INTERP, or DYNAMIC section. Thus elfdump -o iiiissss aaaa ccccoooonnnnvvvveeeennnniiiieeeennnntttt mmmmeeeetttthhhhoooodddd ttttoooo ddddeeeetttteeeerrrrmmmmiiiinnnneeee iiiiffff aaaa pppprrrrooooggggrrrraaaammmm iiiissss lllliiiinnnnkkkkeeeedddd ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd or not. 11110000)))) HHHHoooowwww ddddoooo IIII bbbbuuuuiiiilllldddd aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? To begin with, build a .o or .a which contains all the routines you want to have in your .so (shared object). This can be done with cccccccc ----cccc and aaaarrrr.... Then invoke ld with the ----sssshhhhaaaarrrreeeedddd flag. Normally the extension .so is used to designate shared objects. Here is an example: cc -c myobj.c ld -shared myobj.o -o myobj.so -or- <build libmine.a the usual way.> ld -shared -all libmine.a -o libmine.so The ----aaaallllllll flag in the second example tells ld to include all the routines in the library. This is necessary since there are no undefined references (as in a main(), say) which is the usual way that ld knows to include files from an archive. 11111111)))) WWWWhhhheeeerrrreeee ddddooooeeeessss tttthhhheeee ssssyyyysssstttteeeemmmm llllooooooookkkk ffffoooorrrr sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeeccccttttssss aaaatttt rrrruuuunnnnttttiiiimmmmeeee???? The search path for shared objects is acquired in the following order for the old 32bit ABI: 1) the path of the shared object if given in the liblist, 2) in any directories specified via the ----rrrrppppaaaatttthhhh flag when the executable was built 3) in any directory specified by the LD_LIBRARY_PATH environment variable, if it is defined 4) in the directories in the default path (/usr/lib:/lib:/lib/cc:/usr/lib/cc) If the _RLD_ROOT environment variable is defined, then its value is appended to the front of any path specified by ----rrrrppppaaaatttthhhh and the default path. _RLD_ROOT itself is also a colon(:) separated list. For the new 32bit ABI the rules are similar, but the following differences exist: 1) the LD_LIBRARYN32_PATH is used if defined, otherwise LD_LIBRARY_PATH is used 2) _RLDN32_ROOT is used for the list of paths 3)The default path directory list is (/usr/lib32:/lib32). PPPPaaaaggggeeee 11110000 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) For the 64bit ABI the rules are similar, but the following differences exist: 1) The LD_LIBRARY64_PATH is used if defined, otherwise LD_LIBRARY_PATH is used 2) _RLD64_ROOT is used for the list of paths 3) The default path directory list is (/usr/lib64:/lib64). See the rld(1) manpage for details. 11112222)))) WWWWhhhhaaaatttt iiiissss QQQQuuuuiiiicccckkkkssssttttaaaarrrrtttt???? Quickstart is an optimization. Using an so_locations file, each shared object is pre-relocated by ld, as if it had been loaded at the address in the so_locations file. That way, if nothing unusual happens when we start up the application, all the shared objects will map at their Quickstart addresses, and rld will not need to do a relocation pass over them. If for some reason more than one shared object wishes to map the same address, rld will move one of them to an unused address and perform a relocation pass to fix up the address references. If one or more of the shared objects linked against at static link time has changed by the time the program executes, rld will need to do extra work to ensure that symbols have been resolved to their proper value. 11113333)))) WWWWhhhhaaaatttt iiiissss tttthhhheeee ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee???? In the directory in which you build a shared object, after you've actually built one, you will notice a file named so_locations. It is a registry of shared objects. It maintains the default or Quickstart addresses of a group of shared objects which are to cooperate by not having their default location overlap with one another. It is generated and updated by ld each time it builds a shared object. If you make substantial library changes between one build of the library and another you should remove the so_locations file before rebuilding the library, since the information derived from the older build (and put in the so_locations files) may make the new library build unable to complete successfully. Since _r_q_s_a_l_l(1)/_r_q_s(1) can rearrange a.outs and DSOs to restore quickstartability the so_locations file is less important than it was before _r_q_s existed. 11114444)))) WWWWhhhhaaaatttt ddddiiiirrrreeeeccccttttiiiivvvveeeessss ccccaaaannnn bbbbeeee ppppuuuutttt iiiinnnn aaaannnn ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee???? Comment line so_name [ :st = { .text | .data | $range } base_addr,padded_size : ] * where so_name full path name (or trailing component) of a shared object st string identifying start of the segment description .text | .data segment types: text or data $range limit the range of address that can be used PPPPaaaaggggeeee 11111111 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) base_addr address where the segment starts padded_size padded size of the segment The following directives control the placement of new shared objects: $text_align_size=<align> padding=<pad-size> $data_align_size=<align> padding=<pad-size> These two directives specify the alignment and padding requirements for text and data segments respectively. The size value in so location is calculated based on: (section size + padding) aligned to the section align size The align values for text and data as well as the padding values must be aligned to a bucket size. If not, ld will generate a warning message and align these values to bucket size. $start_address=<addr> Specifies where to start looking for addresses to put shared objects. $data_after_text=[ 1 | 0 ] Instructs the linker to place data immediately after the text at specified text and data alignment requirements. We set the data_after_text to 0 if the argument of this directive is missing. WWWWAAAARRRRNNNNIIIINNNNGGGG:::: TTTThhhheeee ffffoooorrrrmmmmaaaatttt aaaannnndddd uuuusssseeee ooooffff tttthhhheeee ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee iiiissss uuuunnnnddddeeeerrrr rrrreeeevvvviiiieeeewwww aaaannnndddd mmmmaaaayyyy iiiinnnn tttthhhheeee ffffuuuuttttuuuurrrreeee mmmmoooovvvveeee ttttoooo aaaa ssssiiiimmmmpppplllleeeerrrr ffffoooorrrrmmmmaaaatttt.... IIIItttt iiiissss ssssuuuuggggggggeeeesssstttteeeedddd iiiinnnn tttthhhheeee mmmmeeeeaaaannnn ttttiiiimmmmeeee tttthhhhaaaatttt oooonnnnllllyyyy $$$$rrrraaaannnnggggeeee bbbbeeee uuuusssseeeedddd aaaannnndddd nnnnooootttt ....tttteeeexxxxtttt oooorrrr ....ddddaaaattttaaaa iiiinnnn tttthhhheeee ssssppppeeeecccciiiiffffiiiiccccaaaattttiiiioooonnnn.... Also, when building a DSO with the ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy or ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy flag, and if there is already an entry corresponding to this DSO in an so_location file, the linker will try to assign the same addresses for text and data. However, if the size of the DSO changes and does not fit in the specified location any more, the linker will search for another spot that fits. If the optional $range comment is given, the linker will only place the DSO in the specified range of addresses. If there is not enough room, an error will be given. 11115555)))) WWWWhhhhaaaatttt iiiissss ////uuuussssrrrr////lllliiiibbbb////ssssoooo____llllooooccccaaaattttiiiioooonnnnssss???? /usr/lib/so_locations (for the old 32bit ABI), /usr/lib32/so_locations (for the new 32bit ABI), and /usr/lib64/so_locations (for the 64bit ABI) represent the default layout for the system shared objects in the respective ABIs. Developers who build shared objects may find it interesting to consult this file, in order to avoid collisions between their shared objects and system shared objects. This file is absolutely irrelevant to users who merely run programs which use shared objects. There are two options which are relevant, ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy,,,, and <file> looks at <file> and builds the current .so at a location which doesn't conflict with anything in the file (unless the current one is listed. ---- cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy does not write to <file>. ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy <file> will PPPPaaaaggggeeee 11112222 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) consult <file> as with ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy,,,, but will attempt to write an entry for the .so being built into <file>. If <file> is not writable, ---- uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy turns into If <file> is not readable ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy and ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy are ignored. 11116666)))) IIIIffff IIII ddddoooonnnn''''tttt hhhhaaaavvvveeee aaaa vvvvaaaalllliiiidddd ssssoooo____llllooooccccaaaattttiiiioooonnnnssss ffffiiiilllleeee,,,, ccccaaaannnn IIII ggggeeeennnneeeerrrraaaatttteeee oooonnnneeee ffffrrrroooommmm aaaallllllll tttthhhheeee ....ssssoooo''''ssss iiiinnnn,,,, ssssaaaayyyy,,,, ////uuuussssrrrr////lllliiiibbbb???? There is no convenient method to do so. There is no guarantee that all the .so's in /usr/lib have been coordinated so that a consistent so_locations file can be made from them. So it is better to get the one that a particular release was made with. 11117777)))) HHHHoooowwww eeeexxxxppppeeeennnnssssiiiivvvveeee iiiissss iiiitttt ((((aaaatttt rrrruuuunnnnttttiiiimmmmeeee)))) NNNNOOOOTTTT ttttoooo uuuusssseeee ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy ooooppppttttiiiioooonnnn???? If one uses rqsall(1)/rqs(1) to requickstart an application and its DSOs then there need not be any cost. rqs(1) can make the DSOs quickstartable regardless how the DSO addresses were determined. If one does not use rqs then the lack of an updated registry can impose startup costs. It is very difficult to say how much a particular executable will suffer since it depends on which shared objects the program uses and whether they have been Quickstarted for the same address. When there is a conflict between two objects, one will be moved, which means that all addresses referring to names in that object need to be relocated. 11118888)))) HHHHoooowwww aaaannnndddd wwwwhhhheeeennnn wwwwiiiillllllll QQQQuuuuiiiicccckkkkssssttttaaaarrrrtttt bbbbeeee uuuusssseeeedddd???? Normally, the linker will use Quickstart unless there are unresolved symbols at static link time. In every executable and every shared object is a list of objects which were looked at at static link time -- when the object was made. This list also contains timestamps and checksums for each of the objects. Various levels of extra work are required if the timestamp or checksum has changed in the library at run-time. 11119999)))) WWWWhhhhaaaatttt aaaabbbboooouuuutttt rrrruuuunnnn----ttttiiiimmmmeeee llllooooaaaaddddiiiinnnngggg uuuunnnnddddeeeerrrr uuuusssseeeerrrr ccccoooonnnnttttrrrroooollll???? We support an interface known as libdl, which allows users to dynamically load their own shared objects as needed. The calls are dlopen() -- open a new shared object and get a "handle" to it. dlsym() -- find the value of a name defined in an object. dlclose()-- close a shared object. dlerror()-- report errors. sgidladd() -- functions much like dlopen however it exposes all symbols to the rest of the program. PPPPaaaaggggeeee 11113333 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) sgidlopen_version -- functions much like dlopen however it allows specifying a specific required version of the DSO. Consult the individual manpages for details. 22220000)))) WWWWhhhhaaaatttt bbbbeeeennnneeeeffffiiiittttssss wwwwiiiillllllll IIII ggggeeeetttt ffffrrrroooommmm DDDDSSSSOOOO???? Executables linked with shared objects will be smaller since the shared objects are not part of the executable file image. Executables which use a shared object need not be relinked if a shared object is changed -- once the updated shared object is installed, the executable will pick it up automatically. Shared libraries are much easier to build, use, and debug than static shared libraries. DSO allows application designers to make more machine-independent software. System-dependent routines can be given a uniform interface and a shared object which implements that interface can be built for each different platform. Then an actual application can be shipped as-is ("shrink-wrapped" software) to various platforms and run on them all. DSO gives applications the ability to change the binding of symbols at run time, under user control. 22221111)))) WWWWhhhhaaaatttt ccccoooossssttttssss aaaarrrreeee aaaassssssssoooocccciiiiaaaatttteeeedddd wwwwiiiitttthhhh DDDDSSSSOOOO???? A shared object incurs two costs, both against performance. At startup, there will be a startup cost while rld maps in the various objects, performs symbol resolution, etc. We believe this cost is small compared to the time it takes to contact the X server, for example. A shared object's text must be PIC (position independent code). PICification is accomplished by the code generator/assembler when the ---- KKKKPPPPIIIICCCC flag is specified. ----KKKKPPPPIIIICCCC is the default, so it is not necessary to supply the ----KKKKPPPPIIIICCCC flag. PIC code is necessarily slower. Experiments have indicated that this speed reduction is usually less than 5 percent, but can be as much as 15 percent. depending on the application. With full optimization the speed reduction can be near zero. PIC code seems to be worst on very small leaf routines which access global data. 22222222)))) WWWWhhhhaaaatttt iiiissss tttthhhheeee ----KKKKPPPPIIIICCCC ooooppppttttiiiioooonnnn???? This the default, so you need never use it. This flags tells the code generator/assembler to generate PIC directly. The result is an object file that can be put into a DSO without further modification cc -KPIC -c foo.c will give you a PIC object foo.o. Other drivers (cc, pc, f77, and as) also accept the -KPIC option. This is the default. PPPPaaaaggggeeee 11114444 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) Routines written in assembly language need to be modified before -KPIC can be used. See the question below. PIC objects generated by using -KPIC must be compiled -G 0. 22223333)))) MMMMuuuusssstttt mmmmaaaaiiiinnnn pppprrrrooooggggrrrraaaammmmssss wwwwhhhhiiiicccchhhh wwwwaaaannnntttt ttttoooo uuuusssseeee DDDDSSSSOOOOssss uuuusssseeee ----KKKKPPPPIIIICCCC ffffoooorrrr ccccoooommmmppppiiiillllaaaattttiiiioooonnnn???? Yes. DSOs use -KPIC so that position-independent code will be generated. Main programs are not generally position-independent, but must still use the DSO calling convention when calling a routine which is defined in a DSO. In particular, this means that a main program must have a GOT, and the code which is generated must use it. Therefore, modules which will become part of main programs must be compiled -KPIC as well as modules which become part of DSOs. 22224444)))) HHHHoooowwww ddddoooo IIII cccchhhhaaaannnnggggeeee mmmmyyyy aaaasssssssseeeemmmmbbbbllllyyyy llllaaaannnngggguuuuaaaaggggeeee ssssoooouuuurrrrcccceeeessss ttttoooo uuuusssseeee ----KKKKPPPPIIIICCCC???? The following refers to the older 32 bit abi using ucode compilers. For n32 and 64 bit abi information, look at the information and pointers in the aaaabbbbiiii((((5555)))) manpage. Several new assembler directives are added to support generation of PIC. You should also get yourself familiar with the MIPS ABI Supplement and the PIC coding model it describes. In addition, files which are to be assembled with -KPIC must also be -G 0. This is normally turned on by the driver by default. Note that with the exception of (a) and (d), all other directives described below will be ignored when -KPIC is not explicitly specified. Also, item (d), ".gpword", will be turned into ".word". The result will be a NON-PIC version of the same routine. a) .option pic2 This directive forces the assembler to mark the output object file "PIC" and activates the following directives. It overrides the command line argument. Normally, you don't need to specify this directive. Instead, you should use the ----KKKKPPPPIIIICCCC or ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd flags to toggle between generating PIC or non-PIC. Note that even though ----KKKKPPPPIIIICCCC will be made the default for the high- language driver (cc/pc/f77) in future releases, it will *NOT* be the default for assembly sources. You will always have to explicitly specify ----KKKKPPPPIIIICCCC for compiling .s files. b) .cpload reg This directive expands into three instructions that sets the gp register to the context pointer value for the current function. The three instructions are: lui gp,_gp_disp addui gp,gp,_gp_disp addu gp,gp,reg PPPPaaaaggggeeee 11115555 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) _gp_disp is a reserved symbol defined by the linker to be the distance between the lui instruction and the context pointer. This directive is required at the beginning of each subroutine that uses the gp register. You must add this directive at the beginning of every procedure, with the exception of leaf-procedures that do not access any global variables, and procedures that are static (i.e., not marked .globl or .extern). c) .cprestore offset This directive causes the assembler to issue sw gp,offset(sp) at the point where it appears. Additionally, it causes the assembler to emit lw gp,offset(sp) after every jump-and-link (jal) or branch-and-link (bal) operation, thereby restoring the gp register after function calls. The programmer is responsible for allocating the stack space for the gp. This space should be in the saved register area of the stack frame to remain consistent with MIPS' calling and debugger conventions. d) .gpword local-sym This directive is similar to .word except that the relocation entry for local-sym has the R_MIPS_GPREL32 type. After linkage, this results in a 32-bit value that is the distance between local-sym and the context pointer (i.e. the gp). local-sym must be local. It is currently used for PIC switch tables. e) .cpadd reg This adds the value of the context pointer (gp) to reg. EXAMPLES: This is a simplified version of the "hello world" program: -------------------------------------------------------------- .option pic2 .data .align 2 $$5: .ascii "hello world\X0A\X00" .text .align 2 main: .set noreorder .cpload $25 .set reorder subu $sp, 40 sw $31, 36($sp) .cprestore 32 la $4, $$5 jal printf PPPPaaaaggggeeee 11116666 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) move $2, $0 lw $31, 36($sp) addu $sp, 40 j $31 ---------------------------------------------------------------- The actual instructions generated by the assembler will be: lui gp,0 # addiu gp,gp,0 # generated by .cpload addu gp,gp,t9 # lw a0,0(gp) # gp-relative addressing used lw t9,0(gp) # t9 is used for func. call addiu sp,sp,-40 sw ra,36(sp) sw gp,32(sp) # from .cprestore jalr ra,t9 # jal is changed to jalr addiu a0,a0,0 lw ra,36(sp) lw gp,32(sp) # activated by .cprestore move v0,zero jr ra addiu sp,sp,40 nop ---------------------------------------------------------------- NOTE: The MIPS ABI requires that register t9 ($25) be used for indirect function calls, so .cpload should always use $25. No reorder mode should also be used. Also, programmers should make sure that t9 is dead before any function call because the register will be changed (and not restored) during the function call. If your program uses an indirect jump (jalr), you must also use t9 as the jump register. If you have an unconditional jump to an external label: j _cerror you have to rewrite it into indirect jump via t9, i.e.: la t9,_cerror j t9 If you use branch-and-link (bal) instruction, and if the target procedure begins with a .cpload, you have to specify an alternate entry point: foo: .set noreorder # callee .cpload $25 .set reorder $$1: ... # alternative entry point ... j $31 # foo returns PPPPaaaaggggeeee 11117777 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) bar: ... # caller ... bal $$1 # by-pass the .cpload ... This is very important because .cpload assumes register $25 contains the address of foo, but in this case $25 is not set up. Note that since both foo and bar reside in the same file, they must have the same value for $gp. So the .cpload instructions can be and must be bypassed. However, since foo can still be called from outside, the .cpload is still required. Alternatively, if you don't want to have an alternate entry point, you can set up register $25 before the bal: la t9,foo bal foo but this will be less efficient. position-independent jump table (or any table of text addresses). Entries of the address table created by .gpword are converted into displacement from the context pointer. To get the correct text address, .cpadd should be used to add the value of gp back to them. Since the gp is updated by the run-time linker, the correct text address can be reconstructed regardless of the location of the DSO. 22225555)))) CCCCaaaannnn IIII mmmmiiiixxxx IIIIRRRRIIIIXXXX 4444 ssssttttaaaattttiiiicccc sssshhhhaaaarrrreeeedddd lllliiiibbbbrrrraaaarrrriiiieeeessss wwwwiiiitttthhhh DDDDSSSSOOOOssss???? No. 22226666)))) WWWWhhhhaaaatttt ooooppppttttiiiioooonnnnssss ddddoooo IIII hhhhaaaavvvveeee wwwwhhhheeeennnn bbbbuuuuiiiillllddddiiiinnnngggg aaaa sssshhhhaaaarrrreeeedddd oooobbbbjjjjeeeecccctttt???? If you specify the flag ----BBBBddddyyyynnnnaaaammmmiiiicccc while linking a shared object, symbols in the shared object will be resolved differently than the default linkage convention. In particular, the runtime linker will always try to resolve any symbols referenced in that object to symbols defined in that object first, instead of looking for definitions in objects in the order specified on the link line. The effect of this is to make all symbols defined and used in such objects non-preemptable. Ordinarily a such symbol definitions could be preempted by a definition in an earlier shared object, but when -Bsymbolic is specified, this is not the case. 22227777)))) WWWWhhhhaaaatttt ppppiiiittttffffaaaallllllllssss aaaarrrreeee aaaassssssssoooocccciiiiaaaatttteeeedddd wwwwiiiitttthhhh DDDDSSSSOOOO???? Behind most surprises is the fact that linking semantics are fundamentally different, but only in a subtle way. Let us suppose that your program links with three libraries, libA, libB and libC, in that order. Further suppose that both libA and libC define some symbol x, but don't use it. Furthermore, let us suppose that libB contains a reference to x. Archive linking (the old way) will resolve B's reference to x to the definition in C, whereas shared object linking will resolve B's reference to x to the definition in A. PPPPaaaaggggeeee 11118888 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) Why the difference? With archive linking, when libA is examined, there is no outstanding reference to x, hence the definition of x is not extracted from the archive. Later when libC is examined, there is a reference to x, so it is loaded. With shared objects, all the constituent object files have been joined into one object, so all symbol definitions are always present. The resolution rule is simple, take the definition in the object listed first. Thus the definition in libA is used. Another sort of surprise is the "runtime dangling reference". It is altogether possible to build and link an application with no errors or even warnings, only to get a message from rld stating that your program has unresolvable symbols. What's going on? Well, if you build a shared object as part of your program, the linker will not normally complain about undefined symbols during a link of a shared object. This is because undefined symbols are expected during such a build and are perfectly acceptable. But if the main program does not use a symbol, it does not get flagged as undefined during static linking. Thus the runtime "surprise". You can use the ---- nnnnoooo____uuuunnnnrrrreeeessssoooollllvvvveeeedddd flag to the linker to avoid such surprises. Now we turn to a nasty pitfall which can be avoided by some cleverness in building a shared object. If a particular object in an archive has an external reference to a data symbol (which it expects to be defined in main, libl.a, for example) the linker would not try to resolve that external unless the object file in question was actually referenced by the main program. If that archive is turned into a shared object naively, the external data reference must be resolved whenever ANY function in the shared object is used, even if no function in the object file in question is ever called and no use is made of the external data symbol in question. This can lead to a scenario where a user has a link that worked with the archives, but builds a program which gets terminated by the runtime linker (_r_l_d). It is a very bad idea to convert libraries which contain external data symbols to shared objects naively. One thing that can be done is to split the archive into several shared objects which are placed on the liblist of a "master" shared object. Since rld will not by default try to resolve data symbols until the first call is made to a particular object we can create the situation where no attempt to resolve the offending external data symbol is made until a call is made to the object in which it is referenced. Here's an example of how that works: Let us suppose that has_extern_data.o is an object with an undefined external in it which resides in the archive libxyz.a Here is how to isolate that external data reference: PPPPaaaaggggeeee 11119999 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) First make has_extern_data.o into a shared object all its own. % ar x libxyz.a has_extern_data.o % ld -shared has_extern_data.o -o has_extern_data.so Now, make libxyz.so, excluding has_extern_data.o from being included directly, but instead putting it in the liblist of libxyz.so % ld -shared -all -exclude has_extern_data.o libxyz.a has_extern_data.so -o libxyz.so Another pitfall is attempting to have data references from one _s_g_i_d_l_a_d_d()ed DSO to another. When the first is _s_g_i_d_l_a_d_d()ed the data references are unsatisfied and not resolved. Any use of the data before doing the second _s_g_i_d_l_a_d_d() will get the unresolved value. And then after _s_g_i_d_l_a_d_d()ing the value will change! 22228888)))) WWWWhhhhaaaatttt sssshhhhoooouuuulllldddd IIII ddddoooo aaaabbbboooouuuutttt aaaa GGGGOOOOTTTT oooovvvveeeerrrrfffflllloooowwww???? By default, addresses are loaded out of the Global Offset Table (GOT) using a 16 bit offset from a context pointer. This means that the size of the GOT is limited (by default) to 64K bytes, or about 16 K symbols. When there are too many symbols referenced by a DSO (or a.out) the linker issues the message "GOT overflows" and will specify an object file which references the symbol which is "out of reach". When developers encounter this problem, they sometimes attempt to split the DSO or a.out in question into several smaller DSOs, each of which can conform to the GOT size limit. Good performance can be achieved this way, and we have routinely recommended this approach. However it is usually more practical (easier and better performance) to use -multigot, and this is now the preferred solution. Use the ----WWWWllll,,,,---- mmmmuuuullllttttiiiiggggooootttt flag on the link line of the program/DSO being constructed when using CC or cc or f77. Use ----mmmmuuuullllttttiiiiggggooootttt on the ld command line if using ld directly (as one would with a C DSO for example). As a last resort, developers may wish to use the ----xxxxggggooootttt compile-time flag to tell the compiler to issue a different (and slower) code sequence uses a 32-bit offset. This will allow the GOT to contain up to 1G entries. It is critical that every object linked into a final DSO or a.out be compiled with ----xxxxggggooootttt turned on, otherwise code may have been generated which will not work with an extended GOT. However, files compiled with ----xxxxggggooootttt may be linked into a DSO or a.out which has a GOT that does not exceed the 8K symbol limit for 64-bit objects (16K for 32-bit objects) and will work correctly, if somewhat slower. The GOT size of any shared objects linked is irrelevant. The directory /usr/lib/xgot contains the extended-GOT versions of those objects which SGI has built both normally and ----xxxxggggooootttt.... If a system or third party archive contains small GOT objects which are needed in an extended GOT link, a developer can take the following steps: 1) Look in /usr/lib/xgot to see if an extended GOT version exists. 2) Turn the archive into its own shared object, thus isolating it from the extended PPPPaaaaggggeeee 22220000 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) GOT binary. 3) contact the archive provider. In a few cases (crt1.o, crtn.o, c++init.o, and fixade.o), where the performance issues were minimal, the default objects in /usr/lib are in fact built large GOT. Now that ----mmmmuuuullllttttiiiiggggooootttt exists there is no reason to accept the performance penalty of ----xxxxggggooootttt.... 22229999)))) HHHHoooowwww aaaarrrreeee mmmmuuuullllttttiiiipppplllleeee vvvveeeerrrrssssiiiioooonnnnssss ooooffff DDDDSSSSOOOOssss ssssuuuuppppppppoooorrrrtttteeeedddd???? IRIX 5.0.1 (Compilers v3.16) and later supports the ability to tag shared objects and executables with a version number. This is intended to support interface changes. Details are below; items marked (SGI ONLY) do not apply to MSIG ABI binaries, but only to binaries generated on IRIX without the ----aaaabbbbiiii flag turned on. Versioning of Shared Objects. QUICK OVERVIEW For a shared object to be versioned the following needs to be done: Version strings consist of 3 parts and a dot: The string "sgi", a decimal number (the major number), a dot, and a decimal number (the minor number). Add the command -set_version sgi1.0 to the command to build the shared object (cc -shared, ld -shared, etc.). Whenever you make a COMPATIBLE change update the minor version number (the one after the dot), and add the latest version string to colon- separated list of version strings, e.g., -set_version sgi1.0:sgi1.1:sgi1.3 Whenever you make an INCOMPATIBLE change, update the major version number. Pass this as the version list, e.g., -set_version sgi2.0. Change the filename of the OLD shared object by adding a dot followed by the previous major number to the filename of the shared object. DO NOT CHANGE the soname of the object. No change to the file contents are necessary or desirable. Simply rename the file. HOW IT ALL WORKS Versioning is only available for NON-ABI executables. The current ABI does not require objects to have versioning, nor does it require systems to pay attention to versioning. It does allow objects to contain version strings, but does not require systems to do anything with this information. NON-ABI compliant executables will have the RHF_SGI_ONLY bit turned on in the .dynamic section. This flag will be understood and reported by elfdump -L -long. Only executables with this flag on will get the versioning treatment described below. This RHF_SGI_ONLY will be on by default. When an executable is linked against a shared object, the last entry of PPPPaaaaggggeeee 22221111 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) the shared object's version string is recorded in the executable as part of the liblist. This can be examined by elfdump -Dl. When an executable is linked, the user may specify -require_minor or -ignore_minor for each shared object linked against. If -require_minor is specified, a bit will be set in the flags field of the liblist entry for the shared object in question. The default is -ignore_minor. When an executable (ABI or RHF_SGI_ONLY) is run rld will look for the proper filename in its usual search routine. (SGI_ONLY) If a file with the correct name is found the version string in the liblist is compared to the list of version strings in the shared object. If the LL_REQUIRE_MINOR bit is set in the liblist entry, and there is an exact match between the version string in the depender and one of the strings in the version list of the dependee, then that library is used. If the LL_REQUIRE_MINOR bit is clear, and if there is a match of major versions, then that library is used. (SGI_ONLY) If no proper match is found, a new soname is built by taking the soname found in the executables liblist, and the major number found in the version string corresponding to that liblist entry, and putting them together as <soname>.<major> This is searched for in the same way as above. Version strings are matched in exactly the same way as described above. 33330000)))) WWWWhhhhyyyy aaaarrrreeee tttthhhheeee gggglllloooobbbbaaaallll oooobbbbjjjjeeeeccccttttssss iiiinnnn mmmmyyyy CCCC++++++++ DDDDSSSSOOOO nnnnooootttt bbbbeeeeiiiinnnngggg iiiinnnniiiittttiiiiaaaalllliiiizzzzeeeedddd???? Did you link your DSO using the CCCCCCCC command (instead of using lllldddd directly)? See the NNNNOOOOTTTTEEEE:::: After the first example in this man page, that discusses how to create a C++ DSO. 33331111)))) WWWWhhhhyyyy aaaarrrreeee ssssoooommmmeeee lllliiiibbbbrrrraaaarrrriiiieeeessss oooonnnnllllyyyy aaaavvvvaaaaiiiillllaaaabbbblllleeee aaaassss aaaa DDDDSSSSOOOO,,,, wwwwhhhheeeerrrreeee aaaassss ooootttthhhheeeerrrr lllliiiibbbbrrrraaaarrrriiiieeeessss aaaarrrreeee aaaavvvvaaaaiiiillllaaaabbbblllleeee aaaassss bbbbooootttthhhh aaaa DDDDSSSSOOOO aaaannnndddd aaaannnn aaaarrrrcccchhhhiiiivvvveeee???? The ABI specifies which DSOs must be on every system. The converse of that is that no one can assume that any other .so is on an ABI conforming system. Libraries explicitly called out in the MIPS ABI are considered part of the system interface; and the decision was made to only ship such system interfaces in DSO form. Libraries that are not specified in the MIPS ABI must also be supplied in archive form to generate MIPS ABI compliant binaries using these libraries. For example the libraries: libX11.so,and libc.so.1 are explicitly called out in the MIPS ABI making the DSO version of Xlib and libc a system interface. Other examples are libsocket.so and libdl.so which are also only supplied as DSOs. Archive versions of libXt.a, libXm.a,libm.a libmalloc.a, etc... are supplied because shared library versions of these libraries are not specified in the MIPS ABI, therefore they are not guaranteed to exist on all ABI conforming systems. PPPPaaaaggggeeee 22222222 DDDDSSSSOOOO((((5555)))) DDDDSSSSOOOO((((5555)))) 33332222)))) WWWWhhhheeeerrrreeee ccccaaaannnn IIII ffffiiiinnnndddd mmmmoooorrrreeee ddddooooccccuuuummmmeeeennnnttttaaaattttiiiioooonnnn oooonnnn DDDDSSSSOOOO???? Besides the other manpages mentioned below, _S_y_s_t_e_m _V _A_p_p_l_i_c_a_t_i_o_n _B_i_n_a_r_y _I_n_t_e_r_f_a_c_e and _S_y_s_t_e_m _V _A_p_p_l_i_c_a_t_i_o_n _B_i_n_a_r_y _I_n_t_e_r_f_a_c_e -- MIPS Processor Supplement and _M_I_P_S_p_r_o _N_3_2 _A_B_I _H_a_n_d_b_o_o_k (in IRIS Insight) are good sources of DSO implementation details. SSSSEEEEEEEE AAAALLLLSSSSOOOO abi(5), rld(1), ld(1), elf(5), elfdump(1), dlopen(3), sgidladd(3), sgidlopen_version(3),sgidladd(3), sgigetdsoversion(3),gp_overflow(5) UUUUPPPPDDDDAAAATTTTEEEESSSS This man page is periodically updated; the last update done on 1996/December/20 for IRIX 6.[234]. PPPPaaaaggggeeee 22223333 
